Skip to content

Fix OAuth2 client-secret encoding with Base64 padding #17674

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

academey
Copy link

@academey academey commented Aug 9, 2025

Summary

This PR adds compatibility support for OAuth2/OIDC providers that expect Base64 padding characters ('=') to remain unencoded in client secrets when using the CLIENT_SECRET_POST authentication method.

Context

As discussed in #17629, the current behavior of URL-encoding '=' to '%3D' is actually standards-compliant with:

  • RFC 6749 (OAuth2) which requires application/x-www-form-urlencoded encoding
  • RFC 4648 section 5 which states padding '=' should be percent-encoded in URLs

However, some OIDC providers don't properly handle URL-encoded padding characters, causing authentication failures.

Details

  • Added special handling for CLIENT_SECRET_POST authentication in AbstractRestClientOAuth2AccessTokenResponseClient
  • Created utility class OAuth2ClientCredentialsGrantRequestEntityUtils to handle form parameter encoding while preserving Base64 padding
  • Added test case to verify Base64 padding is preserved in client secrets

Compatibility Note

This change is a compatibility enhancement rather than a bug fix. It helps Spring Security work with OIDC providers that don't strictly follow the standards.

Test Plan

  • Added unit test getTokenResponseWhenClientSecretPostWithBase64PaddingThenPaddingNotEncoded to verify the fix
  • Tested with actual OAuth2 providers that require unencoded Base64 padding
  • Verified existing tests still pass
  • Confirmed no regression for other authentication methods

Open Questions

Should this behavior be configurable to maintain strict standards compliance by default?

Closes gh-17629

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 9, 2025
When using CLIENT_SECRET_POST authentication method with a client secret
that ends with Base64 padding characters ('='), the padding was being
URL-encoded to '%3D'. This caused authentication failures with some
OAuth2 providers that expect the padding characters to remain unencoded.

This commit adds special handling for CLIENT_SECRET_POST authentication
to preserve Base64 padding characters in the client secret while still
properly encoding other form parameters.

Closes spring-projectsgh-17629

Signed-off-by: Hyunjoon Kim <[email protected]>
Signed-off-by: academey <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OIDC token-request client-secret %3D instead of = for padding
2 participants